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© An interactive graphical tool is provided for de- 
signing the user interface of a program-controlled 
instrument (30). The tool runs on a computer work- 
station (15 to 19) and is used to model the applica- 
tion code of the instrument as a first network in 
which sessions of user interaction with the applica- 
tion code are represented by respective elements of 
the network. The actual user interaction sessions 
themselves are modelled by respective second net- 
works; each second network includes information for 
^•defining the interface states of the modelled user 
^interaction session. The full user interface can there- 
q> after be simulated by progressing through the first 
LO model until a user interaction element is met and 
PNhen entering the corresponding second network; the 
^interface state information contained in the second 
CD network is used to drive a simulation of the instru- 
~ ment interface on the display of the computer work- 
O station. The separation of the modelling of the ap- 
Q. Plication code from that of the user interaction ses- 
Qjsions facilitates modification of the interface simula- 
tion. 
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USER INTERFACE SIMULATION AND MANAGMENT FOR PROGRAM-CONTROLLED APPARATUS 



The present invention relates to the simulation 
and management of the user interface of „ a 
program-controlled apparatus and, in particular, but 
not exclusively, to an interactive graphical tool for 
designing user interfaces on a computer worksta- 
tion. 

Any interactive system, such as many modern- 
day instruments, can be seen as having two com- 
ponents, namely a user interface and the system- 
executed, or application, tasks. In the past, the 
system functioning required to execute the applica- 
tion tasks has been the focus of product develop- 
ment with interface design being secondary. With 
the increasing complexity of interactive systems, it 
has been recognised that the design of the user 
interface is at least as important as that of the 
underlying functionality of the system and, indeed, 
in commercial terms, possibly more important. 

Considerable efforts have therefore been made 
recently to develop suitable tools for user interface 
design and evaluation. One approach adopted has 
been to use augmented state transition networks to 
model the functioning of the interface. Thus, Was- 
serman has developed a methodology for interface 
design, known as the USE methodology, that incor- 
porates both user-interaction actions and 
apparatus-executed tasks in a single transition net- 
work with the provision for sub-networks (see "The 
Role of Prototypes in the User Software Method- 
ology", Wasserman and Shewmake; published in 
"Advances in Human Computer Interaction", Ablex 
Publishing Co., 1984). Similarly, Alty has devel- 
oped an interface modelling system, known as the 
CONNECT system, which is based upon a com- 
bination of a transition network and a production 
rule system (see "The Application of Path Algebras 
to Interactive Dialogue Design" published in Behav- 
iour and Information Technology, 1984, Vol3, 
No.2). 

It is an object of the present invention to pro- 
vide an interface design tool which facilitates the 
creation and modification of user-interface models 
and the generation of interface simulations. 



Summary of the Invention 

According to one aspect of the present inven- 
tion, there is provided a method of simulating, on a 
computer, a user interface for a program-controlled 
- apparatus arranged to- operate in-accordance-wrth-a- 
program that includes both apparatus-executed 
tasks and sessions of user interaction intended to 
be effected via input and output means of said 
apparatus, said method comprising the steps of: 



-generating and storing a first network model repre- 
senting said program with each session of user 
interaction being indicated by a corresponding ele- 
ment of said first model; 
5 -generating and storing a set of second network 
models each representing a respective one of said 
interaction sessions, each second network model 
comprising a network of elements each having an 
associated set of parameters defining a simulation 
70 of a desired state of said output means, 

- running a simulation of the user interface by 
advancing through said first network model and 
upon encountering a said user-interaction element, 
entering and following through the appropriate one 
75 of said second network models, the said set of 
parameters associated with each said network 
model being used to construct, on output means of 
the computer, a simulation of the desired state of 
the output means of said apparatus. 
20 By separating out the user-interaction sessions 

into respective network models, modification of the 
interface design is greatly facilitated. 

Preferably, during passage through a said sec- 
ond model while running a simulation of the inter- 
25 face, the output means of the computer is used to 
display simultaneously both the second model and 
the simulation of the current state of the output 
means of said apparatus. 

Generally, a number of different possible paths 
30 will exist through each second network. To provide 
for this situation during running of the simulation, 
the step of interface simulation advantageously in- 
cludes, during passage through a multiple-path 
second network model, the determination of the 
35 path to be followed through the model by operator 
input to the computer to indicate the path desired. 
This user input may indicate the desired path di- 
rectly by reference to the second model. Alter- 
natively, the user input may simulate a possible 
40 input of the interface under design, this input being 
then compared against pre-stored path-selection 
criteria to determine the subsequent path to be 
followed through the second model. 

Preferably, the step of generating and storing a 
45 set of second network models is repeated to pro- 
vide simulations of a plurality of different sets of 
user interaction sessions, the step of simulating the 
user interface including the selection of one of said 
sets of second network models from which to call 
50 up the second network model to be used upon a 

user-interaction -element-being-encountered-during- 

progress through said first model. 
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To facilitate the simulation of various different 
types of output means, a library of simulations is 
advantgeously provided, one parameter of each 
said set of parameters used to define a desired 
output state serving to indicate the relevant library 
simulation. 

According to another aspect of the present 
invention, there is provided, in a program-controlled 
apparatus having input and output means for per- 
mitting user interaction sessions with an application 
program intended to be run or modelled on said 
apparatus, an arrangement for managing the 
user/program interaction comprising: 
-first network modelling means representing said 
program with each session of user interaction be- 
ing indicated by a corresponding element of said 
first modelling means; 

-a set of second network modelling means each 
representing a respective one of said interaction 
sessions, each second network modelling means 
comprising a network of elements each having an 
associated set of parameters defining a desired 
state of said output means, 

-control means arranged to utilise said first model- 
ling means to control the actual or simulated run- 
ning of the application program, said control means 
being operative upon encountering a said user- 
interaction element in the first modelling means, to 
refer to the appropriate one of said second network 
modelling means to control the said output means 
in executing a user interaction session, the said set 
of parameters associated with each said element of 
the second modelling means being used to set the 
output means in its desired state. 

The program-controlled apparatus may be a 
computer work-station being used to model a user 
interface for an item of equipment, or it may be a 
piece of production equipment whose operation is 
managed by reference to network models. 



Brief Description of the Drawings 

A user-interface design tool embodying the in- 
vention will now be particularly described, by way 
of non-limiting example, with reference to the ac- 
companying drawings, in which: 

Figure 1 is a diagrammatic representation of 
the hardware and software components both of the 
interface design tool itself and of an instrument for 
which a user interface is to be designed; 

Figure 2 is an augmented transition network 
modelling the application program intended to drive 
the instrument whose user-interface is to be de- 
signed; 



Figure 3A & B are augmented transition net- 
works modelling user-interaction sessions that oc- 
cur during running of the instrument application 
program; 

5 Figure 4 is a diagram illustrating the data 

structures used by the interface design tool to 
store the network models of Figures 2 and 3; 

Figure 5 is a flowchart of a main control 
program of the interface design tool software; 

70 Figure 6 is a flowchart showing part of a 

network editor program of the design tool software; 

Figure 7 is a diagram showing the functional 
realationship of a simulation program of the design 
tool software with other software components of the 

75 tool; 

Figure 8 is a flowchart of the simulation 
program; 

Figure 9 is a diagram representing the func- 
tional inter-relationship of the various software com- 
20 ponents of an instrument whose user-interface is 
managed in accordance with the present invention. 

Description of the Preferred Embodiment 

25 

As shown in Figure 1 . the user-interface design 
tool now to be described comprises both hardware 
components and software components. The hard- 
ware components are the standard components of 
30 a computer workstation and comprise a processor 
box 15, a disc storage device 16, a first input 
device in the form of keyboard 17, a second input 
device in the form of a mouse 18, and a display 
unit 19. In standard manner, the processor box 15 
35 comprises a central processing unit 20 interfacing 
via a bus system 23 with memory (namely, volatile 
RAM memory 21, non-volatile ROM memory 22 
and the disc device 16) and also with the display 
unit 19 via a display controller 24, with the key- 
40 board 17 via a first I/O controller 25, and with the 
mouse 18 via a second I/O controller 26. 

The software components of the design tool 
comprise the Interface design tool software itself 
(referred to below as the IDT software) and the 
45 usual system software providing facilities such as 
file management, screen handling (including win- 
dowing, icons, pulldown menus), and servicing of 
the keyboard and mouse input devices. The IDT 
software itself comprises three main elemems, 
so namely, a main control program 27, a network 
editor program 28 (referred below as the NEED 
program) and a simulation program 29 (referred to 
as the NEST program). 

In order to facilitate an understanding of the 
55 operation of the interface design tool, the following ■ 
description of the tool is made with reference to the 
design of an interface for a hypothetical instrument 
30 depicted in Figure 1. This hypothetical instru- 
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ment is intended to check whether a voltage or 
current measure at a specified test point is within 
predetermined limits, the results of this determina- 
tion being output to the user. In hardware terms, 
the instrument comprises probes 31 circuitry (not 
shown) for executing the measurement an3« deter- 
mination functions of the Instrument, a user inter- 
face constituted by a touch screen 32 and an input 
keypad 33, and a microprocessor (not shown) for 
controlling the overall operation of the instrument. j 
The touchscreen 32 is designed to receive user 
input via softkeys 34 and to output to the user by 
setting legends on the softkeys and by text line 
display on the rest of the screen. The microproces- 
sor hardware controls the components of the instru- i 
ment in accordance with an application program 35 
which governs both the carrying out of instrument- 
executed tasks (such as voltage or current mea- 
surement) and the interaction of the instrument with 
the user via the interface hardware. 2i 

The interface design tool is to be used to 
design an instrument interface which upon switch 
on the instrument will present the user with the 
following four choices (via soft keys 34) with selec- 
tion of a choice resulting in the indicated action: 21 

1) 'HELP" - selection of this choice will bring 
up HELP text on the screen 32, the subsequent 
operation of a soft key labelled "Proceed" returning 
the user to the initial four-choice menu; 

2) "V MEASURE" - selection- of this choice 30 
causes the instrument to ask for the input of a test 
point number (the instrument supposedly storing 

the acceptable range of values for each test point 
in memory); after a test point has been input the 
instrument carries out the required measurement 35 
and compares the result with the pre-stored range 
of acceptable values and then outputs an 
acceptable/unacceptable indication as text on the 
display 32. Return to the opening menu is effected 
by pressing a softkey labelled "Proceed"; 40 

3) "I MEASURE" - selection of this choice 
results in a sequence of actions similar to that 
following selection of the previous choice except 
that a current rather than a voltage is measured; 

4) "EXIT" - selection of this choice shuts 45 
down the instrument after a check is made that ail 

test points have been tested; if this is not the case, 
the user is asked to confirm that he wishes to shut 
down the instrument. 

The first step in designing a user-interface for 50 
the instrument is to model the operation of the 
instrument in terms of augmented transition net- 
works with the instrument-executed tasks being 
modelled using a single application model that 
includes e lejnents_i_ndictive^of_sessions^of-user-— 55- 
interaction with the basic task-executing code; the 
sessions of user-interaction are themselves sepa- 
rately modelled by respective dialogue network 



models. An application network modelling the func- 
tionality of the above-described hypothetical instru- 
ment is shown in Figure 2. As can be seen, the 
basic components of this model are nodes repre- 
senting states of the instrument and depicted as 
square boxes in Figure 2, and arcs representing 
actions and indicated by arrows in Figure 2. Five 
types of nodes may be distinguished, as follows: 
START NODE - this is the starting node of a 
network (see node 40 of Figure 2); 
END NODE - this is the finish node of a network 
model (see node 48); 

APPLICATION SUBNET NODE - this node repre- 
sents another network 

which forms a sub-network of the application model 
and is used to avoid any one network from becom- 
ing over complicated (see node 42 in Figure 2); 
COMMUNICATION NODE - this node indicates a 
point in the communication network where there is 
a session of user-interaction, this session being 
modelled by a dialogue network (see node 41); 
SIMPLE NODE - the purpose of this node is to 
facilitate routing decisions through the network and 
the separation of actions (see node 46). 

As noted above, the application subnet nodes 
and the communication nodes refer to other net- 
works. In Figure 2, these networks are identified by 
names given in quotation marks beneath the re- 
ferencing nodes. 

Each arc of the network is defined by its start- 
ing and finishing node. Accordingly, in the following 
description the arcs will be referred to by combin- 
ing the reference numerals of their starting and 
finishing nodes; thus, for example, the arc extend- 
ing between nodes 40 and 41 will be referenced as 
arc 40/41. Each arc has an associated condition for 
entry to the arc from its starting node. In the 
drawings, this condition is given in square brackets 
on the arc concerned. An arc condition may be set 
to "unconditional" in which case no condition is 
indicated on the arc in the drawings. The action to 
be undertaken by the instrument on transition of 
the arc is indicated by the non-bracketed label 
associated with the arc; the absence of the label 
indicates the absence of an action. 

Referring now in detail to the application model 
of Rgure 2, the desired functionality of the instru- 
ment as described above is modelled as follows. 
Upon switching on the instrument (node 40), a user 
is presented with a menu of four choices and the 
further operation of the instrument depends on the 
user selection input received in response to pre- 
sentation of the menu; this session of interaction 
with the user is indicated in the Figure 2 applica- 

tion-model-by-the communication node 4r labelled " 

"MENU". Note, that the arc 40/41 has no asso- 
ciated condition or action. To model the user selec- 
tion input, a variable "k" is used, this variable 
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having a value of 1, 2, 3 or 4 depending on 
whether the HELP, V MEASURE. I MEASURE, or 
EXIT OPTION is chosen. The HELP option merely 
involves an extension to the userinteraction session 
represented by the communications node 41 . How- 5 
ever, selection of any one of the other options 
involves instrument functionality which must be re- 
presented by an extension of the application 
model. The communication node 41 thus has three 
exit arcs 41/42. 41/44, and 41/46, the conditions on 10 
these arcs respectively being K = 2, (the V MEA- 
SURE option), K = 3 (I MEASURE option) and K 
= 4 (EXIT option). 

The selection of the V MEASURE option re- 
sults in the instrument carrying out a voltage mea- 75 
surement and comparing the result with a stored 
range of acceptable values. This instrument-ex- 
ecuted task involves a series of instrument actions 
which can be modelled by suitable network con- 
figation; however, rather than including this network 20 
representation in the top-level application model 
shown in Figure 2, for reasons of clarity this series 
of actions is best represented in an application 
sub-network indicated in the top level network by 
means of an application sub-network node (in the 25 
present case, node 42 labelled "V-MEAS"). Follow- 
ing the execution of the voltage measurement task 
and comparison of the result with the stored limits, 
the results of these tasks are displayed to the user; 
this display process is, of course, a user-interaction 30 
session and is represented in the application model 
by a communications node 43 labelled "V-DISP". 
The display process when terminated is then fol- 
lowed by a return to the selection menu; this is 
represented by arc 43/41 in the application. 35 

Selection of the I MEASURE option results in 
instrument-executed current measurement tasks 
followed by a results display, this process being 
similar to that for voltage measurement. The cur- 
rent measurement process is represented in the 40 
application model by an application sub-network 
indicated by node 44 labelled "l-MEAS"; the user- 
interaction session by which the current measure- 
ment results are displayed is represented by the 
communications node 45 labelled "l-DISP". 45 

The selection of the exit option from the menu 
results in one of two actions depending on whether 
or not all the test points that the instrument expects 
to be accessed have in reality have been examined 
by the user. This check is indicated in the applica- so 
tion model as an action earned out on the "K = 4" 
arc exiting the communications node 41 . In order to 
model the the subsequent decision process a sim- 
ple node 46 is positioned at the end of the "K = 4" 
arc and two exit arcs from the node 46 are pro- 55 
vided leading to nodes 47 and 48 respectively. The 
node 48 is an exit node modelling shutdown of the 
instrument and the arc leading from node 46 to the 



exit node 48 carries a condition that a variable 
ALLPOINTS is true, this variable being set by the 
checking action on arc 41/46. The arc 46/47 carries 
the complementary condition of ALLPOINTS being 
false; in this case, a user-interaction session is 
initiated asking the user to confirm that he really 
•does wish to shut down the instrument, the alter- 
native being to return to the menu. Node 47 is thus 
a communications node (labelled "CONFIRM" in 
Figure 2). The conditions on the two exit arcs from 
the node 47 relate to a variable CONFIRM derived 
from the user-interaction session modelled by the 
dialogue network associated with the communica- 
tions node 47. When CONFIRM is true, the arc 
leading to the exit node 48 is taken; when CON- 
FIRM is false, the arc leading to the "MENU" 
communications node 41 is taken. 

It will be seen from Figure 2 that the applica- 
tion model modelling the instrument functionality 
includes four communication nodes representing 
four separate sessions of user-interaction. Each of 
these users-interaction sessions is modelled by a 
corresponding dialogue network model. By way of 
example, the dialogue model of the user-interaction 
session represented by the "MENU" communica- 
tions node 41 will now be described with reference 
to Figure 3. 

The elements of a dialogue model are the 
same as those used in an application model with 
the exception that application subnet nodes are, of 
course, not utilised in a dialogue model; H should 
however, be noted that hierachical structuring of 
dialogue models can still be achieved since the 
inclusion of a communication node in a dialogue 
model serves this purpose, such a node being a 
representation of a lower-level dialogue network 
model. Figure 3A shows the top-level dialogue 
model corresponding to the "MENU" communica- 
tions node. This top-level dialogue model com- 
prises a start node 50, two simple nodes 51, 52, 
two communication nodes 53, 54 and an exit node 
55. The action of setting up the four softkeys for 
menu selection is ascribed to the arc 50/51. For 
reasons of simplicity, this action is separated from 
the subsequent action of getting a softkey input by 
the simple node 51, the setting of the softkey input 
being placed on arc 51/52. The user selection of 
one of the softkeys is taken as setting the variable 
k to a value of between 1 and 4. If trie HELP 
softkey is selected (K = 1) then HELP text is dis- 
played on the screen together with a "Proceed" 
softkey which, when activated, returns the user to 
the selection menu. This series of actions is mod- 
elled by providing an exit arc 52/53 from the sim- 
ple node 52 with a condition of the arc of K = 1. 
The node 53 is a communication node that referen- 
ces a dialogue model desscribing the HELP ses- 
sion; this "HELP" dialogue model is shown in Fig- 
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ure 3B and simply involves the actions of setting 
up a "PROCEED" softkey followed by display of 
the HELP text and the waiting for an input cor- 
responding to activation of the "PROCEED* soft- 
key; activation of this key leads to the screen text 5 
being blanked and exiting of the "HELP" dialogue. 
Following completion of the "HELP" dialogue 
model, an arc 53/51 is followed back to node 51, 
this arc carrying the action of setting up the menu 
softkeys. 70 

if one of the measurement options is chosen 
via the menu softkeys (K=2 or 3) then the user is 
asked to input a number identifying the test point 
on which the measurement is to be made. This 
user-interaction is represented in Figure 3A by the 75 
communications node 54 accessed via the arc 
52/54. Once a test point reference number has 
been input, the "MENU" interaction session is ter- 
minated to enable the instrument to carry out nec- 
essary measurements; this is modelled by the arc 20 
leading from the node 54 to the exit node 55 of the 
Figure 3 A dialogue model. 

User-selection of the exit softkey from the 
menu is modelled by the arc 52/55 leading from 
the simple node 52 the exit node 55 and carrying 25 
condition of K-4. 

Suitable network models for the application 
sub-networks represented by nodes 42, 44 and for 
the dialogue models represented by the commu- 
nication nodes 43, 45. 47 and 54 will be apparent 30 
to persons skilled in the art on a reading of the 
foregoing description and will therefore not be de- 
scribed in detail hereinafter. 

The operation of the present interface design 
tool takes place in two distinct phases. The first 35 
phase involves the construction, by interactive 
graphical techniques, of application and dialogue 
models of the form described with respect to Fig- 
ure 2 and 3 together with the specification of vari- 
ables to be used with the models and conditions 40 
and actions to be associated with the arcs of the 
models. The second phase involves the simulation 
of instrument user interface by stepping through 
the application and dialogue models and presenting 
on the display 19 of the computer workstation a 45 
simulation of the instrument interface as seen by 
the user at each stage and as defined by the 
appropriate actions associated with the arcs of the 
dialogue models. Before describing in detail the 
programs used to control these two phases of 50 
operation of interface design tool, it will be useful 
first to describe the data structures employed to 
store the application and dialogue models pro- 
duced during the first phase and utilised during the 
second, -simulation phase. — - - . — ss — 



Referring now to Figure 4, the details of each 
network whether it be the top-level application 
model, an application sub-network model, or a dia- 
logue model are stored in a respective network file 
60. This network file 60 contains the network name 
by which the network and file are iu'SMified, the 
network type, (application or dialogue), an arc table 
61 containing details of each arc making up the 
network concerned, a node table 62 detailing the 
nodes of the network, and a variable table 63 listing 
the variables used in the network. 

Each node in the node table 62 is detailed in a 
data structure 67 that contains the following items; 

1) An indication of the node type (start, end, 
simple, application subnet, or communication 
node); 

2) The name of the node; 

3) The graphical position of the node on the 
screen (the node screen position is related to a 
notional screen grid the intersections of which de- 
fine potential centre points for the nodes, the node 
position being specified as a reference number 
associated with a particular grid intersection) no- 
tional screen grid referred to above. 

Each arc in the arc table 61 is represented by 
a data structure 64 containing the following items: 

1) The identity of the arc starting node as 
represented by the number of that node in the 
node table; 

2) The identity of the arc end node as in- 
dicated by the node index in the node table; 

3) The name of the arc; 

4) The condition set on the arc, if any; 

5) A pointer to a data structure 65 identifying 
the action associated with the arc, if any. 

The data structure 65 contains the name of the 
action to be taken and a pointer to a link list 66 of 
the arguments relating to the named action. 

Figure 5 is a flowchart of the main control 
program of the IDT software. This program ba- 
sically controls migration between the network-ed- 
iting phase and the network simulation phase. 

Upon loading of the main program 27 (block 70 
in Figure 5) the user is first asked whether he 
wishes to work with an existing network model or to 
create a new one (block 71); in the former case the 
user inputs the name of the existing network and 
the corresponding network file is loaded into a 
working memory of the workstation (block 72) 
whereas in the latter case the user inputs the name 
of the new network model to be created and the 
main program opens a new file for that network 
(block 73). 
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Thereafter the user is asked whether he wishes 
to enter the network editor program NEED or the 
simulation program NEST or whether he wishes to 
exit the interface design tool package (see blocks 
74 to 77). After completion of an editing or simula- 
tion session, the user is again given the opportunity 
to select the function he desires. 

The functioning of the network editor program 
NEED will now be described with reference to 
Figure 6. This program allows the graphical cre- 
ation and editing of networks and, at the same 
time, takes care of the creation and editing of the 
data structures storing the network details. 

On entering the NEED program the user is 
given the choice of selecting one of four functions 
(block 80), these functions being: 
ADD 
DELETE 
COPY 
MOVE 

The ADD function enables the user to add new 
nodes and arcs to build or extend a network model 
and this function will now be described in more 
detail below. 

After selection of the ADD function, the user is 
asked whether he wishes to add a node or an arc 
(block 81). If the user elects to add a node, a new 
entry is created in the node table 62 of the cor- 
responding network file (block 78). Next, the user 
selects the type of node required (block 82). If the 
user elects to add a start node, the program as- 
sumes that a new network is being created and will 
at this stage ask the user to define what variables 
he wishes to' use in the network (blocks 83, 84): the 
variable definitions are stored in the variable table 
63 of the network file. 

The user now proceeds to identify the screen 
position where he wishes the new node to be 
located; advantageously this is achieved using the 
mouse 18 to position the screen cursor 95 (see 
Figure 1) and then to indicate to the program when 
the cursor is in the desired position. The node 
centre position is then located at the nearest inter- 
section point of the notional screen grid mentioned 
above and the system graphics software is used to 
draw a node centered at this location (see blocks 
85, 86). The grid intersection number is stored in 
the corresponding node data structure 67 (see 
block 87). The user is then asked to name the 
node and this name is also stored in the node data 
structure 67. Thereafter, the program returns to the 
function-select block 80. 

If. after selection of the ADD function, the user 
elects to add an arc to the current network, then 
the program creates a new entry in the arc table 61 
(block 79). The user then proceeds to define the 
arc by using the mouse 18 to point the cursor 95 to 
the start and end nodes of the arc (block 89). This 



information is used by the program to cause the 
system graphics software to draw an arc on the 
screen between the indicated nodes (block 90); at 
the same time, the node-table indexes of the start- 

5 ing and end nodes are entered into the corre- 
al sponding entry in the arc table (block 91). The user 
is then asked for the name of the arc (block 92) 
following which the user can define any conditions 
and actions on the arc (blocks 93. 94) all this 

jo information being entered into the corresponding 
arc-table entry. 

Using the ADD function a desired network can 
be graphically constructed on the display screen 
19 with the defining information on the network 

75 being stored in the various data structures of the 
corresponding network file. The other selectable 
functions (Delete. Move, and Copy) facilitate the 
editing of a network; the detailed operation of these 
functions will not be described herein as such 
20 operation will be apparent to persons skilled in the 
art. 

In Figure 6, the operations of defining the vari- 
ables, arc conditions and arc actions are indicated 
as occurring at the time of node and arc creation. 
25 In practice, a user may .find it more convenient to 
first construct his desired network model as quickly 
as possible without having to define the variables, 
conditions and actions, these latter being added 
later. In order to facilitate this approach, these 
30 operations may be accessed directly from the func- 
tion choice block 80, the appropriate definitions 
being then added once the arc or node of interest 
has been identified. 

It should be noted that It is not in fact neces- 
36 sary to define ail variables, conditions and actions 
in order to run a minimum simulation of a user 
interface under design, all that is necessary is to 
define the dialogue-network arc actions that control 
the interface. With this information a simulation 
40 may be run by "walking through" the network 
models and simulating on the display screen 19 
the user interface as defined by dialogue network 
arc actions. In this "walk through" mode of simula- 
tion the path taken through a network must be 
45 specified by the user since without defining vari- 
ables and conditions the network models cannot 
simulate the functionality of the instrument applica- 
tion program. 

However, a fuller simulation can be achieved if 
so variables and conditions ace defined as this en- 
ables the user to converse with the simulation, the 
paths taken through the network models being then 
made dependent on user input to the simulation. 
This simulation mode is referred to as the 
55 "prototype" mode. 
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A full simulation of the instrument's functional- 
ity can be achieved by defining actions on the 
application network arcs that correspond to the 
tasks carried out by the instrument. 

The definition of the dialogue-network actions 
take the form of action names that refer to library 
routines for simulating particular interface types. 
Furthermore, each action wifi generally have one or 
more associated arguments definining the detailed 
implementation required of a specified interface 
type. Thus, for example, in the present example it 
is desired to simulate an instrument in which the 
interface output involves use of softkeys and use of 
text output. This can be achieved by provided two 
library routines, one for defining softkeys and one 
for creating text output. The arguments of the soft- 
key action call may, for example, be the number of 
softkeys required and the softkey legends; the ar- 
guments for text line action may be the desired 
text and the screen coordinates for where the text 
is to appear. 

A similar library of routines may be used to 
define the arc actions of the application network 
model. However, generally these routines will be 
dummy routines rather than ones actually following 
the instrument functionality in every detail. 

In the present interface design example for the 
instrument 30 of Figure 1, dummy routines may be 
provided to simulate the application tasks of volt- 
age measurement (part of the V-MEAS sub-net- 
work) current measurement (part of the l-MEAS 
sub-network) and the ALL POINTS check on arc 
41/46. 

To run a simulation, the NEST program is first 
loaded together with the starting network for the 
simulation (this may be either the top-level applica- 
tion network if a simulation of the whole interface is 
required, or some other network if only a simulation 
of part of the the interface is to be effected). As 
illustrated in Figure 7, the simulation program 
NEST then carries out a simulation by utilising the 
application and dialogue models concerned (100 
and 101), the library of interface action routines 
102, the system software 103. and the library of 
dummy instrument-task routines 104. 

The operation of the simulation program NEST 
will now be described in detail with reference to the 
flowchart of Figure 8. On loading of the program, 
the display screen 19 is split into a network window 
for displaying the selected network and a simula- 
tion window for displaying the user interface sim- 
ulation (these actions are embodied in block 110 of 
Figure 8). 



The simulation program establishes a current 
position for the simulation and at the start of a 
simulation this will be the starting node of the 
current network (block 111); this "current position" 
5 is indicated to the user by highlighting of the ap- 
propriate network node. 

To progress through the network and thereby 
run a simulation, the user first selects whether he 
wishes to carry out the simulation in the "walk 
w through" or "prototype" mode (block 112). The 
mode selected remains set until changed. 

The program then proceeds to identify the arc 
next to be traversed (block 113). The manner of 
this identification will depend on the simulation 
75 mode selected. In the case of the "walkthrough" 
mode, the next arc to be traversed is indicated^by 
pointing to the terminating node of that arc using 
the mouse 18. If the prototype mode has been 
selected then the arc next to be traversed will 
20 depend on the conditions on the arc and the cur- 
rent states of the simulation variables as set by 
user input and simulated instrument-executed 
tasks. Once the arc to be followed has been iden- 
tified, the program traverses the arc and executes 
25 any action of the arc (block 114). As already in- 
dicated, the execution of an action will involved 
reference either to the library of application rou- 
tines 104 if the current model is an application 
model, or to the library of interface routines 102 if 
30 the current model is a dialogue model. Where a 
dialogue-network arc action specifies a user-inter- 
face simulation, this simulation is displayed in sim- 
ulation window. 

Having traversed an arc, the "current position" 
35 is updated to that of the arc-end node with the 
latter being illuminated in the network window. 
Thereafter the node type is examined (blocks 115, 
116 and 117) and appropriate action taken. If the 
node is a communications node or an application 
40 sub-network node then the corresponding dialogue 
network or application sub-network is automatically 
loaded (blocks 118, 119) and replaces the parent 
network in the network window. In order to keep 
track of this nesting of networks, the program both 
45 records the last "current position" in the parent 
network and also keeps account of the nesting 
depth (blocks 120 and 121). Once the new network 
has been loaded and the nesting housekeeping 
operations have been performed, the program 
so loops back to block 111 to continue the simulation 
by starting at the start node of the new network. 

If the arc-end node is a simple node rather 
than a communications or subnet node then the 

Program-loops -back-to-block Ti 2-for mode-selec- 

55 tion and determination of the next arc to be tra- 
versed. 
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If the arc-end node is not a communications, a 
subnet node, or a simple node, it is assumed to be 
an end node in which case the program checks the 
current nesting depth to see if the network just 
completed was the top-level one for the current 5 
simulation. If the "nesting depth is zero (block 122),^ 
then the simulation program is terminated. On the 
other hand, if the nesting depth is not zero the next 
level network is reloaded and displayed in the 
network window; at the same time, the nesting w 
depth is updated and the "current position ■ is 
indicated in accordance with the stored position for 
the new network (see blocks 123 and 124). The 
simulation program then loops back to block 112. 

By way of example, consideration will now giv- is 
en to running a simulation of the networks of Fig- 
ures 2 and 3. Assuming that intially the application 
model network of Figure 2 is loaded, then initially 
this network will be displayed in the network win- 
dow with its starting node highlighted. The Simula- 20 
Won window will be blank. 

If the walkthrough mode is selected, the sim- 
ulation is progressed by the user using the mouse 
18 to indicate in the network window, node 41 
thereby defining the arc 40/41 as the next arc tobe 25 
traversed. This arc is then traversed but no action 
is executed as none has been specified on the arc. 
The current position is then advaned to node 41. 

Since node 41 is a communications node, the 
simulation program proceeds to load the corre- 20 
sponding dialogue network, this being the MENU 
dialogue network of Figure 3A. The dialogue net- 
work is displayed in the network window as is 
illustrated in Figure 1. The new current position is 
node 50 of the dialogue model. Walkthrough then 35 
continues with the arc 50/51 being traversed. This 
results in the execution of an action for setting up 
softkeys with the arguments of this action being 
four softkeys with the menu selection choices as- 
cribed to these keys. In order to execute the action, 40 
the simulation program refers to the library of inter- 
face routines and selects the softkey routine there- 
from; this routine together with the arguments 
stored in the node table entry for the node 51 
result in a simulation of the instrument display 45 
appearing in the simulation window (as illustrated in 
Figure 1). Once this action is completed the current 
position is moved on to node 51 with the latter 
being highlighted in the network window. 

The simulation is then progressed by the user 50 
pointing to node 52 to cause arc 50/52 to be 
traversed, the action on this arc being the setting of 
the simulation to receive an input by simulated 
operation of the simulated softkeys using the 
mouse 18 and cursor 95. The current position is 55 
advanced to node 52. 



From node 52 there are three possible exit 
arcs each carrying its own condition. While the 
simulation remains in walkthrough mode .the input 
action set up on traversing arc 51/52 and the 
conditions set on the arc exiting node 52 are not 
relevant since the exit from node 52 is defined by 
the user by selection of the next node in the 
network window. Thus, for example, the user may 
select node 53 which causes the MENU dialogue 
network to be replaced in the network window by 
the HELP dialogue network of Figure 3B. In this 
case, the display in the simulation window does in 
fact remain the same until walkthrough of the HELP 
dialogue network is carried out when the four soft- 
keys are replaced by a single softkey labelled 
"PROCEED" and HELP text is displayed on the 
screen. 

Further description of the operation program in 
its walkthrough mode will not be given as such 
further operation will be apparent to persons skilled 
in the art 

Consideration will now be given to running of 
the simulation program in its "prototype" mode. In 
this case, the path followed through a network is 
determined by user input to the interface simulation 
displayed in the simulation window and by the 
conditions set on the network arcs. 

Assuming the prototype mode is selected im- 
mediately follow ing loading of the application 
model of Figure 2, the program will run the simula- 
tion through to node 52 of the Figure 3A dialogue 
network automatically and there wait for the con- 
dition of one of the exit arcs from this node to be 
satisfied before proceeding further. This automatic 
progression through the networks to node 52 is 
advantageously arranged to take place on a step 
by step basis with a pause between each step so 
that the user can follow the progression of the 
simulation. 

In order to satisfy a condition one of the exit 
arcs from node 52, the user must simulate opera- 
tion of one of the softkeys in the simulation window 
by pointing to that key using the mouse 18. This 
action sets a value of 1 to 4 to a variable K defined 
in the variable table of the network file of the 
MENU dialogue model. This variable is global inas- 
much it is not only used in the MENU dialogue 
model but also in the first-level application level. 

If, for example, the simulated "exit" softkey is 
chosen, a value of four is ascribed to the variable K 
with the result that the condition on arc 52/55 is 
satisfied and this arc is traversed by the simulation 
program. On reaching the node 55, the simulation 
program returns to the application network Figure 
and places network in the network window; the 
display in the simulation window remains set at the 
menu softkey simulation. 
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The "current position" in the application net- 
work upon reloading of the latter is the node 41: 
This node has three exit arcs with conditions on 
these arcs based on the variable K. In the present 
case, with K = 4, the simulation automatically exits 
node 41 and traverses the arc 41/46 to node 46. 
The action associated with this arc is the check 
that all test points have been accessed; this action 
may or may not be modelled in the simulation. If 
the action is not modelled then the user must 
revert to the walkthrough mode in order to specify 
the exit arc desired from node 46. However, the 
action may be modelled either by the dummy 
routine or by a full routine. The dummy routine 
may, for example, be arranged to alternate be- 
tween indicating that all points have been checked 
and the converse, this indication being by way of a 
variable ALLPOINTS defined in the variable table of 
the network file of the application model. 

If the dummy, or actual routine is provided for 
the ALLPOINTS check action and this routine re- 
turns the variable ALLPOINTS then, once the ac- 
tion has been completed, the simulation will exit 
the node 46 via the arc 46/47 or 46/48 in depen- 
dence on the state of the variable ALLPOINTS. 

If the variable ALLPOINTS is set True, then the 
"current position" is set to the end node 48. How- 
ever, if the variable ALLPOINTS is set False, then 
the CONFIRM dialogue network is loaded and dis- 
played In the network window. This network is, for 
example, arranged to reset the softkeys to display 
two keys in the simulation window respectively 
labelled "CONFIRM" and "CANCEL". The simu- 
lated operation of these simulated keys is arranged 
to set a variable CONFIRM either true or false and 
return operation to the top-level application model 
The state of the variable CONFIRM will then deter- 
mine the exit arc followed from the node 47. 

The further running of the simulation program 
■n its prototype mode will be apparent to persons 
skilled in the art and is not therefore described 
herein. 

From the foregoing it can be seen that the 
interface design tool permits the rapid modelling of 
the functionality and user-interface of an instrument 
or other program-controlled apparatus. Simulation 
of the actual user interface itself is then achieved 
by introducing appropriate actions on the arcs of 
the dialogue model (in the simplest case) and 
possibly also the introduction of actions and con- 
ditions on the arcs. The ability to be able to follow 
through the progress of the simulation both by 
reference to the network models in the network 
window and by reference to Jhesimulation display 
in- the simulation window greatly facilitates user " 
interface evaluation. Furthermore, the division of 
the model of the instrument's functionality into an 
application model and a plurality of dialogue net- 



work models greatly eases the modification of the 
user interface design since such modification sim- 
ply involves accessing the appropriate dialogue 
models rather than having to upset the underlying 
5 application model. 

It will be appreciated 3that various modifications 
to. the described interface design tool are possible. 
Thus, for example, when running the simulation 
program in its walkthrough mode, the indication of 
io the network arc to be followed may be done more 
than one arc at a time by pointing to a node further 
through the network and arranging for the program 
to work out the route to that node; this of course, is 
only possible where the route is unambiguous. 
75 Another alternative is to allow the walkthough pro- 
cess to progress automatically through the current 
network and only stop to await user guidance when 
a node with multiple exit arcs is encountered. 

To assist the user in keeping track of the 
20 nesting of the application sub-networks and dia- 
logue networks, provision can be made both during 
the network editing phase and the simulation 
phase, for displaying a list of currently-nested net- 
works. In the editing phase, further provision may 
2S be made for transferring from the currently-dis- 
played network to a selected one of the networks in 
the displayed nesting list. 

The general approach described above for run- 
ning the user interface simulation can, in fact, also 
30 be used to manage the operation of a program- 
controlled apparatus such as the instrument 30 
subject of the above described simulation. Thus, 
with reference to Figure 9, the operation of the 
apparatus could be modelled by means of appiica- 
35 tion and dialogue models 130, 131 in the manner 
already described with progress through these 
models being managed by network manager 132 
that functions in a manner similar to the NEST 
program 29. Where the application model 130 calls 
« for an apparatus-executed task, this is implemented 
by the network manager 132 by calling up an 
appropriate block of application code 133. Similarly 
user-interface actions called for by the dialogue 
models 131 are implemented by the network man- 
-« ager 132 by calling up the appropriate dialogue 
code 134. y 

In order to accommodate users of varying de- 
grees of proficiency, a plurality of sets of dialogue 
models can be provided each aimed at a particular 
so level of user proficiency. The selection of which set 
of dialogue models is used could be effected by 
the user himself or could be the subject of intel- 
ligent selection by the network manager based on 
_ _ .past experience with the current user 

55 
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Claims 

1. A method of simulating, on a computer, a 
user interface for a program-controlled apparatus 
arranged to operate in accordance with a program 
that includes both apparatus-executed tasks and 
sessions of user interaction intended to be effected 
via input and output means of said apparatus, 
characterised in that said method comprises the 
steps of: 

-generating and storing a first network model (40 to 
48) representing said program with each session of 
user interaction being indicated by a corresponding 
element (41 ,43,45,47) of said first model; 
-running a simulation of the user interface by ad- 
vancing through said first network model and upon 
encountering a said user-interaction element 
(41,43,45,47), entering and following through the 
appropriate one of said second network models (50 
to 55), the said set of parameters (65,66) asso- 
ciated with each said element encountered during 
transition through a second network model (50 to 
55) being used to construct, on output means (19) 
of the computer, a simulation of the desired state 
of the output means of said apparatus (30). 

2. A method according to claim 1, wherein 
during passage through a said second model (50 to 
55) while simulating said interface, the output 
means (19) of the computer is used to display the 
second model (50 to 55) and the progress of the 
simulation therethrough. 

3. A method according to claim 2, wherein the 
output means of the computer comprises a single 
display (19) used to represent both the second 
network model (50 to 55) and the simulation of the 
current state of the output means of said apparatus 
(30). 

4. A method according to claim 2, wherein the 
output means (19) of the computer comprises re- 
spective display devices for representing both the 
second network model (50 to 55) and the simula- 
tion of the current state of the output means of said 
apparatus. 

5. . A method according to claim 1, wherein in 
order to represent a user interaction session the 
course of which is determined by user input during 
the session, the step of generating and storing said 
second network models includes the generation 
and storage of a said second network model (50 to 
55) with more than one possible path therethrough; 
the step of interface simulation including, during 
passage through the multiple-path second network 
model, the determination of the path to be followed 
through the model by operator input to the com- 
puter to indicate directly the path desired. 

6. A method according to claim 1, wherein in 
order to represent a user interaction session the 
cours of which is determined by user input during 



the session, the step of generating and storing said 
second network models includes the generation 
and storage of a said second network model (50 to 
55) with more than one possible path therethrough 
5 together with decision criteria for determining which 
said path is taxen; the step of interface simulation 
including, during passage through the multi-path 
second network model, the simulation of said user 
input by an operator input to the computer and the 
io determination of the appropriate path through the 
network model by applying said criteria to the 
simulated user input. 

7. A method- according to claim 1 , wherein in 
order to represent a program which has its path 
is between apparatus-executed tasks determined by 
user input during a said user interaction session, 
the step of generating and storing said first network 
model (40 to 48) includes the generation and stor- 
age of a network model with more than one possi- 
20 ble path therethrough; the step of interface simula- 
tion including the determination of the path to be 
followed through the first network model by oper- 
ator input to the computer to indicate directly the 
desired path through the 
25 a A model according to claim 1. wherein in 

order to represent a program which has its path 
between apparatus-executed tasks determined by 
user input during a said user interaction session, 
the step of generating and storing said first network 
30 model (40 to 48) includes the generation and stor- 
age of a network model with more than one possi- 
ble path therethrough together with decision criteria 
for determining which said path is taken; the step 
of interface simulation including: 
35 -during passage through a said second network 
model (50 to 55). the simulation of a said user 
input by an operator input to the computer, and the 
storage of a variable indicative of said input; and 
-the determination of the appropriate path through 
40 the first network model (40 to 48) by applying said 
criteria to the simulated user input. 

9. A method according to claim 1. wherein the 
step of generating and storing a set of second 
network models (50 to 55) is repeated to provide 

<5 simulations of a pluraiity of different sets of user 
interaction session, the step of simulating the user 
interface including the selection of one of said sets 
of second network models from which to call up 
the second network model to be used upon a user- 

50 interaction element being encountered during 
progress through said first model. 

10. A method according to claim 1, including 
the further step of providing a library (102) of 
simulations for simulating different forms of output- 

55 means for said apparatus (30). the said set of 
parameters including a parameter (65) for selecting 
the output means to be simulated, and the step of 
running the simulation including accessing said li- 
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brary in accordance with the current output-means 
selection parameter whereby to simulate the appro- 
priate output means. 

11. In a program-controlled apparatus having 
input and output means for permitting user inter- 5 
action sessions with an application program in- 
tended to be run or modelled on said apparatus, an 
arrangement for managing the user/program inter- 
action comprising: 

-first network modelling means (130) representing 10 
said program with each session of user interaction 
being indicated by a corresponding element of said 
first modelling means; 

-a set of second network modelling means (131) 
each representing a respective one of said inter- 75 
action sessions, each second network modelling 
means comprising a network of elements each 
having an associated set of parameters defining a 
desired state of said output means, 
-control means (132) arranged to utilise said first 20 
modelling means (130) to control the actual or 
simulated running of the application program, said 
control means (132) being operative upon encoun- 
tering a said user-interaction element in the first 
modelling means, to refer to the appropriate one of 25 
said second network modelling means (131) to 
control the said output means in executing a user 
interaction session, the said set of parameters as- 
sociated with each said element of the second 
modelling means being used to set the output 30 
means in its desired state. 
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